[翻译] ASF 新孵化项目提案指导
本文翻译了ASF 孵化器新项目的孵化提案英文编写指导，针对提案模版上的章节内容给出了详细的解释以及示例。通读全文可以帮助大家进一步了解 ASF 孵化器对新孵化项目的提案要求，同时也可以进一步了解新项目在进入孵化器前后需要做哪些具体的工作。
原文链接：
https://cwiki.apache.org/confluence/display/INCUBATOR/New+Podling+Proposal?desktop=true¯oName=markdown
译者： 刘天栋 Ted Liu
校对： 姜宁 Willem Jiang
摘要 Abstract
评注：对项目的简短描述性概述。一段简短的文字，长度最好为一句话。摘要应适合在毕业时用于创建正式项目的董事会决议中重复使用，并作为新孵化项目网站和项目描述 （DOAP: Description of a Project）文件的第一段。
示例:
Geronimo 将是一个符合 J2EE 规范的容器。
Heraldry 将围绕以用户为中心的新兴身份空间开发技术。
Yoko 将成为 CORBA 服务器。
提案 Proposal
评注：较长的建议说明。应具有合理的陈述性。更多的论述性材料应放在理由部分（或后面的其他部分）。
示例:
XAP 提供了一个基于 XML 的声明式框架，用于构建、部署和维护丰富的交互式 Ajax 网络应用程序。XAP 的一个基本原则是利用现有的 Ajax 应用程序…
背景介绍 Background
评论：为不熟悉问题范畴和项目历史的人提供背景资料。解释含义可能被误解的术语（例如，没有一个被广泛采用的定义）。这些内容应该能够被领域专家安全地忽略。这些内容最终可能会出现在新孵化项目的网站上。
示例 （Heraldry）:
Higgins 项目是 Eclipse 正在积极开发的一个框架，它将使用户和企业能够跨多个系统集成身份、个人资料和关系信息。通过使用上下文提供者，现有的和新的系统，如目录、协作空间等，都可以使用 Higgins 项目。
合理性（提案理由）Rationale
评论：解释为什么这个项目需要存在，为什么它应该被 ASF 采用。这里适合讨论性材料。
示例 (Beehive):
在构建 J2EE 应用程序时，我们亟需一个连贯、易用的编程模型。刚刚接触 Java 的开发人员不得不学习大量的 API 来构建简单的应用程序；高级 J2EE 开发人员不得不编写乏味的系统架构描述代码；由于底层的复杂性，工具作者在简化体验方面受到限制。
初始的目标 Initial Goals
评注：复杂的建议（例如，涉及多个现有代码库）可能会让人担心其实用性。解决这些问题的一个好办法是制定一个计划，证明该建议是可行的，并且经过了深思熟虑。
许多项目不需要本节。
示例 （Heraldry）：
将 Yadis 和 OpenID 库扩展到现有 Python、Ruby、Perl 和 PHP 库之外的其他语言，以修订 OpenID 身份验证规范，解决已知的安全问题，研究与 DIX IETF 提案的兼容性，描述 Yadis 集成，并允许使用 URL 或 XRI 作为最终用户标识符
目前状态 Current Status
评注：本部分（以及包含的主题）描述了候选项目的现状和开发实践。这应该是一个诚实的评估，并将其与 Apache 的原则和开发理想相平衡。
对于某些提案来说，这是一个展示对毕业前需要解决的问题的理解的机会。而对于其他提案，这则是一个强调与已有 Apache 之道密切匹配的机会。没有初始代码库的提案应简单说明这一点。
有些提案将这一部分命名为准则（虽然这个词有点误导）。
任人唯贤 Meritocracy:
评注：ASF 是一个任人唯贤的地方。
一旦开发人员提交了足够多的优秀补丁，他们就会很自然地当选为提交者。活跃的提交者被选入项目管理委员会（PMC）也是理所当然的。
这一更新过程对于 Apache 项目的长期健康发展至关重要。这份提案正是证明提案者理解这一过程的合适场所。
示例 （OFBiz）：
OFBiz 最初由 David E. Jones 和 Andy Zeneski 于 2001 年 5 月创建。该项目现在拥有来自世界各地的提交者和用户。项目中较新的提交者是在随后几年加入的，他们最初提交补丁，然后拥有部分应用程序的提交权限，再后来拥有更多应用程序的提交权限。
示例 （Beehive）：
我们计划尽一切可能营造一个支持任人唯贤的环境。XMLBeans 的提交者们学到的经验之一是，优秀的社区不只是从良好的愿望中发展出来的；它们需要积极地向社区寻求帮助，列出/说明需要完成的工作，并跟踪和鼓励做出贡献的社区成员…
社区 Community
评注：Apache 只对社区感兴趣。
候选项目应从一个社区开始，并有可能通过吸引新用户和开发者来发展和更新这个社区。请说明您的提案如何符合这一愿景。
示例（Beehive）：
过去两年中，BEA 一直在围绕该框架的前身建立一个社区。目前有一个活跃的新闻组，可以帮助我们在 Apache 建立一个新的社区。
示例 （WebWork2）：
WebWork 2 社区拥有活跃的邮件列表和论坛，追随者众多。
示例 Example（WADI）：
开源中对全服务集群和缓存组件的需求是巨大的，因为它可以应用于许多领域，从而为一个巨大的社区提供了潜力。
核心开发者 Core Developers
ASF 是由个人组成的。
对初始提交者列表中的开发人员进行简要介绍是非常有用的。最好在这里进行（而不是在初始提交至列表部分才介绍）。本节可用于讨论核心开发团队的多样性。
示例 （ServiceMix）
核心开发人员是一个多元化的开发团队，其中许多人已经是经验丰富的开源开发人员。他们中至少有一名 Apache 成员，还有其他一些现有的 Apache 提交者（Committer），以及来自不同公司的人员。http://servicemix.org/Team。
示例 （WADI）
WADI 由 Jules Gosnell 于 2004 年创立，目前拥有来自 Geronimo、Castor、OpenEJB、Mojo、Jetty、ActiveCluster、ActiveMQ 和 ServiceMix 的强大开发人员基础。
相关性 Alignment
说明为什么您的提案和 Apache 非常匹配。强调您的提案与 Apache 项目和开发理念的联系。
示例 (Beehive):
初始代码库的目标是在 Tomcat 中运行，但我们的目标是让该框架在任何兼容的 Servlet 或 J2EE 容器上运行。基于 JSR-181 的 Web 服务组件将利用 Axis。NetUI 组件基于 Struts。底层控制组件框架使用 Velocity。我们还需要开发其他项目，如 Portals 和 Maven 项目。
已知风险 Known Risks
自我认识的练习。风险并不意味着项目不可接受。如果认识到并注意到这些风险，就可以在孵化期间加以解决。
项目名称 Project Name
说明已采取哪些措施检查项目名称是否合适，以及项目是否获得继续使用其现有名称的法律许可。还请说明广泛使用该名称是否会在将来造成项目所有权人的混淆或品牌问题。
被遗弃的产品 Orphaned Products
对未来发展做出公开承诺。
招募多样化的开发社区和强大的用户群需要时间。ASF 需要确信提议者是有决心的。
示例 (Yoko):
贡献者都是这一领域的领先者。不存在出现孤儿代码或废弃代码的任何常见警告信号的风险。
示例 Example (Ivy):
由于提交者人数较少，因此项目存在成为 “孤儿 “的风险。代码库的主要知识仍由 Xavier Hanin 掌握。即使 Xavier 没有离开 Ivy 开发团队的打算，我们也意识到了这个问题，并且知道需要努力减少项目对个人的依赖。
示例 Example (Tika):
有许多处于不同成熟阶段的项目都实现了 Tika 中建议功能的一部分。对于许多潜在用户来说，现有的工具已经足够，这就减少了对更通用工具包的需求。这一点也可以从过去一年中该提案的缓慢进展中看出。不过，一旦项目启动，我们就可以根据下面提到的种子代码，迅速达到现有工具的功能水平。在此之后，我们相信，基于通用工具包优于定制工具包的优势，开发者和用户社区将迅速发展壮大。
缺乏开源经验 Inexperience with Open Source
如果提案是基于现有的开源项目，并具备开放开发的历史，则应在此处重点说明。
如果初始提交者名单中包含具有深厚开源背景的开发人员，则应在此处强调这一点。
缺乏开源经验是封闭项目选择申请孵化的原因之一。多年来，Apache 在这方面积累了丰富的经验。成功开放一个封闭项目意味着所有参与者都要投入精力。这需要学习和回馈社区的意愿。如果提案是围绕一个封闭项目提出的，并且对开源领域知之甚少，那么请承认这一点，并表现出学习的意愿。
示例 (Cayenne):
Cayenne 于 2001 年作为开源项目启动，至今已有 5 年时间。
示例 (Beehive):
许多提交者都有开源项目的工作经验。其中五人有在其他 Apache 项目中担任提交者的经验。
示例 (Ivy):
虽然 Ivy 是在开源许可证下发布的，但最初对它的访问是有限的，公众无法访问问题跟踪系统或 SVN 资源库。虽然后来情况有所改变 - SVN 仓库可以公开访问，JIRA 实例自 2005 年 6 月起就已建立，许多新功能都是先在论坛或 JIRA 上讨论的 - 但真正开源开发模式的经验目前还很有限。不过，Maarten 在真正的开放源代码开发流程方面已经有了很好的经验，他将把自己的经验带到项目中来。
示例 (River):
最初的提交者在开源项目方面拥有不同程度的经验。他们都参与过以开源许可证发布的源代码，但使用开源开发流程开发代码的经验有限。不过，我们预计在正常的任人唯贤规则下执行不会有任何困难。
孵化期 Length of Incubation
说明：本节说明了项目在升级为顶级项目之前预计需要多长时间的孵化，以及孵化的原因。
这表明项目已经考虑了毕业所需的步骤，没有任何不切实际的期望。
同质的开发人员 Homogenous Developers:
健康的项目需要开发商的组合。开放式开发需要致力于鼓励多样化的混合。这包括在分布式环境中作为地理位置分散的小组的一部分开展工作的艺术。
从一个单一的社区开始并不妨碍项目进入孵化阶段。但对于这些项目来说，致力于创建一个多样化的开发人员组合是有益的。那些已经拥有混合社区的项目应该借此机会突出自己的工作。
示例 (Beehive):
目前的提交者名单包括来自几家不同公司的开发人员和许多独立志愿者。提交者分布在美国、欧洲和亚洲。他们在分布式环境中工作经验丰富。
示例 (River)
由于 Jini 技术入门套件迄今为止主要由 Sun Microsystems 开发，因此该项目的绝大多数初始提交者都来自 Sun。多年来，Sun 收到了其他开发人员提供的错误修复和增强功能，并将其纳入代码。我们的计划是与这些其他开发人员合作，并在取得进展时将他们添加为提交者。最初的提交者还有三位（非 Sun 开发人员）：Bill Venners、Dan Creswell 和 Mark Brouwer。Bill 是服务 UI API 工作的领导者，Dan 参与了许多基于 Jini 的开发，包括名为 Blitz http://www.dancres.org/blitz/ 的 JavaSpaces 服务的实现，而 Mark 则是许多基于 Jini 开发的资深人士，包括 Virgil http://www.virgil.nl 的商业工作以及开源 Cheiron http://www.cheiron.org 项目的领导者。
示例 (Ivy):
只有两名核心开发人员，至少他们不是同质化的！Xavier 和 Maarten 之所以认识，完全是因为他们对 Ivy 的共同兴趣。
对受雇开发人员的依赖 Reliance on Salaried Developers
一个由受雇开发人员主导的项目，如果他们只对自己受雇的代码感兴趣，那么这个项目的长期健康发展就会受到威胁。
Apache 以人为本，而不是以公司为本。我们希望，无论开发人员目前的雇主是谁，他们都能继续参与 Apache 的工作。
这正是表明受雇开发人员和志愿者之间初步平衡的好时机。此外，还可以谈谈开发人员的投入程度。
示例 (OpenJPA):
大多数开发人员都是由他们的雇主支付工资来为这个项目做出贡献的，但是考虑到 Java 社区对 JPA 实现的期待以及提交者对代码的主人翁意识，如果没有受雇开发人员为这个项目做出贡献，这个项目的继续也不会有问题。
示例 (River):
预计 Jini 的开发工作将利用受雇时间和下班后的志愿者时间进行。虽然依赖于受雇开发人员（目前来自 Sun，但预计其他公司的受雇开发人员也会参与进来），但 Jini 社区非常活跃，事情应该很快就会平衡。与此同时，Sun 将在未来支持该项目，为 Jini 提供 “工作时间”，以便顺利过渡。
示例 (Wicket):
虽然有两位开发者 - Martijn和Eelco - 在业余时间编写了Wicket In Action（出版商Manning），但他们都不依赖Wicket做咨询工作。大多数开发者都在日常工作中使用Wicket，有些人还在多个项目中使用，而且随着他们的公司（特别是Topicus、Cemron和Teachscape）选择Wicket作为开发框架，他们还将在相当长的一段时间内使用Wicket。
与其他 Apache 产品的关系 Relationships with Other Apache Products
Apache 项目应愿意与 Apache 内部和外部的其他开源项目合作。候选项目应愿意走出自己的小圈子。
您的提案是一个讨论现有联系的机会。这也是讨论未来潜在联系和计划的合适场所。
Apache 允许不同的项目有相互竞争或重叠的目标。不过，这应该意味着代码库之间的友好竞争和社区之间的真诚合作。
候选项目是现有项目的直接竞争者，还是间接竞争者（问题领域相同，生态利基不同），抑或只是有一些重叠的同行，并不总是很明显。在间接竞争的情况下，摘要必须准确描述生态利基。直接竞争者很有可能会被要求总结与现有项目在结构上的异同。
示例 (OpenJPA):
Geronimo 可能会使用 Open JPA，它需要一些 Apache 产品（regexp、commons collections、commons lang、commons pool），并支持 Apache commons 日志。
示例 (River):
目前，与 Apache 项目的唯一联系是入门套件使用 Ant 构建工具。未来可能会有一些联系（http 服务器、数据库后台等），我们将对此进行探索。
对 Apache 品牌的过度迷恋 An Excessive Fascination with the Apache Brand
过去曾有人担心，有些项目的提出似乎只是为了给提案者带来正面的宣传效果。本节正是让大家相信事实并非如此的好地方。
本节也是在过去曾施行过不端行为之后（例如，如果任何与提案有关的人在过去以与事实不符的方式将自己与 ASF 品牌联系在一起），重新与社区建立联系，并承诺未来良好行为的合适处所。
示例 (CeltiXfire):
虽然我们希望 Apache 品牌有助于吸引更多的贡献者，但我们对启动本项目的兴趣是基于前述 “合理性（提案理由）” 部分中提到的因素。不过，我们也会对无意中滥用 Apache 品牌的行为保持警惕，并将与孵化器项目管理委员会和项目管理委员会合作，确保品牌政策得到尊重。
示例 (Wicket):
ASF 拥有强大的品牌，这个品牌本身就很有吸引力。不过，Wicket 的开发者已经在自己的道路上取得了相当大的成功，继续走下去完全没有问题。我们有兴趣加入 ASF，以增加我们在开源领域的人脉和知名度。此外，我们从一开始就是 Apache 的热心用户（还记得 JServ 吗？
示例 (OpenJPA):
我们认为，Open JPA 将受益于广泛的合作，能够建立一个开发者和提交者社区，其影响力将超过创始人，并将被其他 Apache 项目（如 Geronimo 项目）所接受。
文档 Documentation
更多阅读材料参考。
示例 (Heraldry):
有关 Yadis 的信息，请访问：http://yadis.org http://www.openidenabled.com
有关 OpenID 的信息，请访问：http://www.openid.net http://www.openidenabled.com OpenID 和 Yadis 的邮件列表如下：http://lists.danga.com/mailman/listinfo/yadis
初始代码 Initial Source
描述本提案之代码库的来源。如果初始代码的来源不止一个，则应在此概述不同的历史。
如果没有初始代码，请在此处注明。
示例 (Heraldry):
OpenID 自 2005 年夏季开始开发。它目前拥有一个活跃的社区（超过 1,500 万个启用账户）和多种语言的库。此外，它还得到了 LiveJournal.com 的支持，并继续在开源社区中获得关注。Yadis 自 2005 年底开始开发，其规范自 2006 年初以来一直未变。与 OpenID 一样，它也有各种语言的库，两个社区之间有很大的重叠。
代码和知识产权提交计划 Source and Intellectual Property Submission Plan
复杂的提案（通常涉及多个代码库）可能需要在此为提交代码制定一个初步计划，并证明本提案切实可行。
示例 (Heraldry):
OpenID 规范和 openid.net 上的内容来自 Six Apart 公司的 Brad Fitzpatrick 和 VeriSign 公司的 David Recordon。
域名 openid.net 和 yadis.org 来自 Six Apart, Ltd. 的 Brad Fitzpatrick 和 NetMesh, Inc.
JanRain 公司提供了 Python、Ruby、Perl、PHP 和 C# OpenID 库。
来自 NetMesh 和 VeriSign 公司的 Yadis 一致性测试套件。
我们还将为各种开源软件征集更多插件和补丁。
外部依赖 External Dependencies
初始源的外部依赖性很重要。根据 Apache 政策，只有部分外部依赖是允许的。对于孵化中的项目，这些限制最初（在一定程度上）会比较宽松。
如果初始源存在依赖关系，导致无法毕业，则应在此处说明如何解决这些问题。
示例 (CeltiXfire):
所有依赖项都有与 Apache 兼容的许可证。其中包括 BSD、CDDL、CPL、MPL 和 MIT 许可的依赖项。
加密技术 Cryptography
如果提案直接或间接涉及加密代码，ASF 需要了解情况，以便获得相关文件。
所需资源 Required Resources
邮件列表 Mailing lists
最少需要的列表是 private@{podling}.incubator.apache.org（用于 PPMC 的私密讨论）和 dev@{podling}.incubator.apache.org 列表。请注意，项目历史上曾错误地命名了私有列表 PMC。为避免混淆适当的用法，ASF 决议将所有此类列表重新命名。
如果该项目是开源的新项目，那么从这些最基本的清单开始是最好的方法。最初的重点是招募新的开发人员。早期采用者就是潜在的开发者。随着发展势头的增强，社区可能会决定在必要时创建提交和用户列表。
迁移到 Apache 的现有开源项目可能希望在这里采用与它们相同的邮件列表设置。但是，并不是所有的邮件列表都必须在启动过程中创建。新的邮件列表可以通过新孵化项目列表上的投票来添加。
默认情况下，{podling}的提交将通过电子邮件发送至 commits@{podling}.incubator.apache.org。因此建议采用此命名约定。
邮件列表选项将在其他地方详细介绍。
示例 (Beehive):
private@beehive.incubator.apache.org（有人管理主持的订阅列表）dev@beehive.incubator.apache.org
commits@beehive.incubator.apache.org
Subversion 目录 Subversion Directory
常规做法是使用全小写、以破折号（-）分隔的目录名。目录应位于孵化器目录空间内 (http://svn.apache.org/repos/asf/incubator).
示例 (OpenJPA):
https://svn.apache.org/repos/asf/incubator/openjpa
Git 仓库 Git Repositories
传统的做法是使用全小写、以破折号（-）分隔的版本库名称。资源库的前缀应为 incubator，之后如果项目晋升为顶级项目（TLP），则应重新命名。
示例 (Batchee):
https://gitbox.apache.org/repos/asf/incubator-batchee.git
问题跟踪 Issue Tracking
Apache 使用 JIRA 和 Bugzilla。请选择一个。指明项目在问题跟踪系统中的名称。
示例 (OpenJPA):
JIRA Open-JPA (OPEN-JPA)
其他资源 Other Resources
在此说明提案所需的任何其他特殊基础设施要求。请注意，在允许在核心硬件上提供新服务之前，基础设施团队通常会要求提供令人信服的论据。大多数提案都不需要这一部分。
上面未涉及的大多数标准资源（如持续集成）应在引导后添加。基础架构文档会解释这一过程。
初始提交者 Initial Committers
用于引导社区的提交者列表（注明姓名和电子邮件地址）。标记每个已提交贡献者许可协议 (以下简称 CLA) 的提交者。现有的提交者应使用他们的 apache.org 电子邮件地址（因为他们只需要适当的因果关系）。其他提交者应使用 CLA 上的（或将要使用的）电子邮件地址。这样就可以很容易地将 CLA 与提议的项目提交者匹配起来。
最好在提交提案的同时提交 CLA。将 CLA 存放在 Apache 不会有任何损失，但处理可能需要一些时间。
注意这一点。考虑创建一个单独的板块，让感兴趣的开发人员表达他们的兴趣（并可能留下简要介绍），或请他们在普通邮件列表中发布信息。
示例 (OpenJPA):
Abe White (awhite at bea dot com)
Marc Prud’hommeaux (mprudhom at bea dot com)
Patrick Linskey (plinskey at bea dot com)
…
Geir Magnusson Jr (geirm at apache dot org)
Craig Russell (clr at apache dot org) *
保荐者 Sponsors
这是一个有点争议的话题。Apache 的提交者都是个人，他们以自己的名义在这里工作。评判他们的标准是他们的优点，而不是他们的从属关系。不过，本着全面公开的精神，我们还是希望能在一开始就公开列出任何可能会影响最初提交者独立性的当前附属关系。
例如，那些从事项目工作的受雇开发人员应列出其所属单位。有了这份名单，就可以判断初步名单的多样性程度，从而判断还有多少工作要做。
这最好在提交者列表之外的单独部分进行。
只有初始引导列表中的提交者的隶属关系是相关的。这些提交者并不是按照通常的任人唯贤的程序加入的。我们强烈建议，项目启动后，开发人员应根据其贡献而非背景来评判。引导完成后，不应再保留此列表。
引路者（倡导者）Champion:
引路者是已经与 ASF 有联系的人，他领导提案过程。通常情况下（但并非必须），“引路者” 也会被提名为 “导师”。
应在提案制定过程中找到一位 “引路者（倡导者）"。他的作用是帮助制定提案，并与您一起解决孵化项目管理委员会（IPMC）在审查提案时提出的意见和问题。
被提名的导师 Nominated Mentors:
列出被提名为候选项目的导师[定义]的符合条件（且愿意）的个人的名单。
三位导师提供了一个法定人数，并允许 Podling 从孵化器项目管理委员会获得更多自主权，因此目前的共识是三位导师是一个很好的数字。无论如何，任何有经验的 ASF 社区成员都可以提供非正式指导，重要的是确保 Podling 有足够的固定导师，以便顺利进行。对于 Podling 可以拥有的正式或非正式导师的数量没有限制。
保荐者的实体 Sponsoring Entity
保荐者是 ASF 内负责此提案的组织单位。发起单位可以是 ：
ASF 董事会 The Apache Board
孵化器 The Incubator
另一个 Apache 项目。相应项目的项目管理委员会将决定是否保荐/支持（通过投票）。除非与现有的 Apache 项目有紧密联系，否则建议提案请求孵化器赞助。
请注意，孵化项目最终在 ASF 组织结构中的去向将在孵化毕业时决定。
关于ALC Bei jing
基于对这个问题的思考，我们创建了 ALC-Beijing(Apache Local Community Beijing) ,并且致力于通过（但不限于）下述行动帮助开源爱好者更好地在 Apache 社区生根发芽：
举办线上和线下沙龙，将本地的开发与用户聚焦在一起。
通过分享开源开发经验，鼓励更多的人参与到 ASF 的项目开发中来。
为 ASF 的项目寻找相互合作的机会，让这些项目能够更加茁壮地成长。
介绍 ASF 管理和运作开源项目的成功之道，帮助大家更好地运作开源项目。